Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop running CompatHelper on root project again #1063

Merged
merged 2 commits into from
Feb 2, 2024
Merged

Stop running CompatHelper on root project again #1063

merged 2 commits into from
Feb 2, 2024

Conversation

visr
Copy link
Member

@visr visr commented Feb 2, 2024

In #1021 I enabled to run CompatHelper on the root project, but seeing the flood of PRs this morning and thinking about it some more, I think this was a mistake. We should close all those PRs.

Compat is needed in core for all dependencies. For other dependencies, in principle we shouldn't declare compat, since we use a Manifest anyway. This is similar to the way we allow any version in pixi.toml, and the monthly pixi.lock update also brings in possibly breaking changes that we can then evaluate.

We could have compat entries in the root project. Those makes sense if we are not compatible with newer breaking releases to hold it back. This way the manifest update will not bring in this incompatible release. We should not forget about these, so ideally we have an issue labeled tech-debt for those.

Copy link
Contributor

@Hofer-Julian Hofer-Julian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me

@Hofer-Julian Hofer-Julian merged commit 7d472b7 into main Feb 2, 2024
19 checks passed
@Hofer-Julian Hofer-Julian deleted the compat branch February 2, 2024 08:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants